Hi Robin,
> Comodo is performing a thorough review of all server certificates issued by > Comodo between those dates for domains on the .be and .eu TLDs which used > the domain control validation method described in 3.2.2.4.2 of the BRs. Can you elaborate on how this review is being performed? Does it include human cross-reference of the source images used as input to the OCR system and the produced email address used during domain validation? Thanks! On Wed, Oct 19, 2016 at 10:59 AM, Robin Alden <ro...@comodo.com> wrote: > SUMMARY: > > Comodo was informed by security researchers Florian Heinz and Martin Kluge > that on 23rd September 2016 they had been able to obtain a server > authentication certificate [1] from Comodo for a domain which they did not > own or control. > > The researchers shared their discovery with Comodo and this assisted Comodo > to ensure that no further such certificates were issued. > > > > DOMAIN CONTROL VALIDATION > > One of the methods that Comodo uses to validate that a certificate > applicant > owns or controls a domain to be included in the subjectAlternativeName of a > server authentication certificate is set out in the CA/B Forum's Baseline > Requirements document [2] at section 3.2.2.4.2. > > That method may be summarized as the sending of an email to an email > address > (and obtaining a confirming response) where the email is identified as > belonging to the Domain Name Registrant, technical contact, or > administrative contract as listed in the WHOIS record of the domain. > > > > For the TLDs .eu and .be the registries offer only a redacted port 43 WHOIS > service which does not include the contact email addresses. > > They also offer a web-based WHOIS service which presents the contact email > addresses, but which does so in the form of a graphical image in a page > instead of text. > > For these TLDs (.eu and .be) we were using an OCR system to read the > contact > email addresses. > > > > The researchers disclosed to Comodo that, while obtaining a certificate > from > Comodo for a domain that they did control, Comodo's certificate application > process presented them with an email address which was not the same as they > had registered in WHOIS but which was substantially similar. They inferred > from the nature of the difference between the email addresses that the > difference was due to an error in reading the email address, most likely by > OCR (Optical Character Recognition). > > They verified that the error in transcribing the email address led to a > vulnerability in the certificate application process by identifying a > domain > name which was also subject to the OCR transcription error and, by > registering a domain with the name produced by the transcription error, > were > able to obtain a certificate from Comodo for the domain name which was > subject to the transcription error despite them not controlling it. > > > > The domain that they used for their proof of concept was > > a1-telekom.eu > > The registrant email address in the WHOIS entry was > > domain.bill...@a1telekom.at <mailto:domain.bill...@a1telekom.at> > > which was misread by OCR as > > domain.bill...@altelekom.at > <mailto:domain.bill...@altelekom.at> (the "1" in a1telekom.at was > detected > as a lower case 'L') > > > > IMMEDIATE RESPONSE > > Comodo's immediate response to the disclosure was to revoke the identified > certificate and to disable the use of OCR in the interpretation of WHOIS > responses for the validation new certificate requests. > > > > INVESTIGATION OF SCOPE > > Comodo used an OCR system to interpret WHOIS information from 2 TLDs. The > TLDs were .be and .eu . > > Comodo used OCR for the WHOIS on these two domains between 27-JUL-2016 and > 28-SEP-2016. > > Comodo is performing a thorough review of all server certificates issued by > Comodo between those dates for domains on the .be and .eu TLDs which used > the domain control validation method described in 3.2.2.4.2 of the BRs. > > The review is ongoing but no other examples have been found of certificates > issued as a consequence of OCR mis-reads. > > > > WHOIS > > Comodo notes that the port 43 WHOIS service provided by most registries is > a > valuable source of information for CAs and for other parties who have a > legitimate need to contact domain name registrants. > > Some domain registrars provide registrants with a means to effectively > opt-out of having their contact details made public through the port 43 > WHOIS server, or otherwise, by providing a 'privacy' or 'anonymization' > service whose details appear in the WHOIS results for the domain instead of > those of the registrant. > > Comodo understands that some registrants will not want to be identified and > supports their right to a choice as to whether they should be identified in > WHOIS. > > Comodo understands that some registries do not offer a port 43 WHOIS > service > because they are not able to do so. There are some registries for small or > poor regions where we cannot expect technical excellence. > > Comodo finds it regrettable that some registries choose to offer a port 43 > WHOIS service which redacts information for all registrants which even the > registry themselves would normally consider to be public. We find it even > more regrettable that a sub-set of those registries refuse to consider > offering unredacted access to that information even when contractual and/or > commercial terms (including binding restrictions on the use of that > information) are offered. > > > > Robin Alden > > Comodo CA Ltd. > > > > [1] https://crt.sh/?id=47045653 > > [2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf > > [3] > http://www.heise.de/newsticker/meldung/Zertifikats-Klau-Fatale- > Sehschwaeche- > bei-Comodo-3354229.html > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
